PacketCable is a project conducted by Cable Television Laboratories and its member companies whose goal is to identify, qualify, and support packet-based voice and video products over cable systems. PacketCable is a set of protocols and associated element functional requirements developed to deliver Quality-of-Service enhanced secure communications services using packetized data transmission technology to a consumer's home over the cable television hybrid fiber-coaxial data network. The PacketCable Security Specification is hereby incorporated by reference; and interim PacketCable Security Specification document PKT-SP-SEC-I01-991201, released Dec. 1, 1999 is specifically referenced.
The RC4 (Rivest Cipher 4) algorithm is a stream cipher designed by Rivest for RSA Data Security and is a variable key-size stream cipher with byte-oriented operations. The algorithm is based on the use of a random permutation. It is commonly used to protect Internet traffic using the SSL (Secure Sockets Layer) protocol. RC4 is a variable-key-size cipher developed in 1987 by Ron Rivest for RSA Data Security, Inc. RC4 is used to encrypt media flows for voice and video over packet cable. The algorithm used variable length keys. For PacketCable the key length is set to 128 bits. RC4 is a pseudo-random number generator in output feedback mode. The key-stream is independent of the plaintext. The output stream is generated from the key and stored with the plaintext. There is no integrity protections on the data. RC4 uses a 256 entry substitution box which must be initialized. The entries are a permutation of the number 0 through 255, and the permutation is a function of the variable-length key.
Referring to FIG. 1, an example of a voice encryption system for using RC4 is illustrated. A packet security unit (“PSU”) implements a single channel functionality for encryption/decryption and authentication of voice payload. A PSU is implemented as an independent module, but it is highly correlated to Packetized Voice Protocol Unit (“PVP”) 10 and PVP uses PSU functions through a function pointer. PSU also supports Real Time Protocol (“RTP”) with voice payload only. PSU can be configured to support authentication or encryption with or without authentication. RC4 algorithm is used in encryption, while authentication is based on Multi-linear Modula Hash Message Authentication Code (“MMH-MAC”) algorithm. The MMH-Message Authentication Code (“MAC”) is the message authentication code option for media flows. The MMH-MAC is computed over the RTP header and the payload generated by the codec 22.
A message authentication code (“MAC”) provides security to each packet of a media stream. A MAC ensures the receiver that the packet came from the legitimate sender and that it has not been tampered with en route. A MAC defends against a variety of potential known attacks, such as replay and clogging. It also may defend against as-yet-undiscovered attacks. Typically, a MAC consists of eight or more octets appended to the message being protected. A two or four byte MAC can be chosen during configuration for PacketCable. The encryption keys and keys lengths are configurable, for example the RC4 key can require 128 bits. A MAC key and key length are configurable as well. The maximum MAC key length should be the maximum RTP packet length plus the number of MAC digits. An exemplary voice payload size is 240 bytes (30 ms*80 PCM samples/10 ms). The maximum RTP header length should be 12 bytes plus the maximum contributing source identifiers (CSRC) length of 64 bytes, or 72 bytes. The MAC key length should then be at least 316 bytes. The RC4 and MAC keys are initialized by loading key messages from MIC.
In FIG. 1, in the PVP transmit side (TX) 12, the PSU receives packets from the codec 22, encrypts one frame of voice payload, and performs the message authentication on one RTP packet. Packets are sent to and received from a network driver unit (NDU)20. At the PVP receive end (RX) 14, the PSU performs the message authentication on the receive packets first, then decrypts the voice payload. After the receiving packets through PSU RX 14, packets are sent to a voice playout unit (VPU) 16, after which they are sent back to the codec 22. According to the RC4 algorithm, RC4 states must be synchronized with an RTP packet timestamp and the RC4 state adjustments are involved in both PVP TX 12 and RX 14 directions. Because of network packet delay jittering and voice activity detection operations, PVP 10 may not receive any packets for a long period of time. The next received packet will require a large amount of RC4 states adjustments in that case. In order to avoid interrupting a conversation by adjusting the RC4 states during voice transmissions, RC4 decryption states are adjusted during a no packet arrival period. A 2.5 ms local clock is used in the RC4 decryption states advance function.
The RC4 algorithm has been specified for use in an RTP (Real Time Protocol) stream in PacketCable. The algorithm applies only to the RTP payload, not the header, and does not add any additional bytes to the voice packets. The algorithm assumes that voice payload packets are part of one large data stream. The state must be maintained over packet boundaries, however, and even over codec 22 changes. The timestamp field in the RTP header is used to keep the sender and receiver RC4 states synchronized. The state of the RC4 encryption process is preserved between frame encodings. The RC4 process operates as if the payload of each frame is padded up to length (Ne+Nm) octets, where Ne is the maximum size of the payload of an event packet (the value of Ne is at least as large as Nc which is the number of octets in one frame of compressed audio; Nc is a consent value that depends on the voice codec and on the audio frame size; the payload of a voice packet contains the Nc octets making up one frame of compressed audio), and Nm is the number of MAC octets; with a value of zero if the optional MAC is not selected, or two or four which represents the MAC size if the optional MAC is selected. The payloads of all packets are concatenated into a single stream. The stream is encrypted by a single RC4 encryption process.
RC4 encryption state Nk is the number of keystream octets that have been previously generated by the RC4 encryption process, whether used or discarded. Nk has value 0 immediately after the RC4 process is initialized with a new key and increments with each generated octet of keystream. Nk is used both in RC4 encryption and MAC process. For each frame, the RC4 encryption state Nk should be set to the value Nf(Ne+Nm), where Nf is the codec frame number, and Ne is the maximum size of the payload of an event packet; and Nm is the number of MAC octets. This value is 0, if the optional MAC is not selected, or 1 or 2 which represents the MAC size if the optional MAC is selected. The octets of the packet's payload are encrypted using the RC4 encryption process and inserted into the payload field. If there are B octets to be encrypted, then they are encrypted using octets Nk+Nm to Nk+Nm+B−1, inclusive and in order in the RC4 key-stream. The Nm octets from Nk to Nk+Nm−1 are used in MAC digit calculation. Not all of the key-stream octets generated by the RC4 process are necessarily used. The RC4 encryption process is advanced for silent codec frames that are not actually transmitted, since the value of Nf increments even for silent frames. Since the codec calls operates continuously at codec frame rate during conversation, TX RC4 encryption state synchronization involves updating Nk to Nf (Ne+Nm) according to the current frame number Nf The next expected frame number Nf_next (16 bits) is used to represent the RC4 state.
Prior to decrypting the packet's payload or verifying its Mac digits, RC4 decryption state at the receiver side, RX, must match the RC4 encryption state of sender side TX. The RC4 decryption state Nk should be set to the value Nf*(Ne+Nm) as well, where the maximum payload size Ne and the number of MAC octets Nm should be the same as the transmit side TX during the channel setup. The frame number Nf is computed from the value of timestamp field in the packet header. The timestamp field is a 32-bit value that reflects the sampling instant of the first uncompressed speech sample encoded in the packet. The timestamp field is used by the receiver to synchronize its decryption process to the encryption process of the sender. The starting times of two communicating parties are independent and their time difference is arbitrary. The starting time differences could be beyond the timestamp threshold in timestamp check. A MIPS based RC4 state adjustment algorithm is used for RC4 states adjustment in the first receive packet.
Therefore, the timestamp value is very crucial for RC4 decryption state synchronization, the receiver should perform a check on the timestamp value in the RTP header. A timestamp check state is used to check if the timestamp of the current packet is in a reasonable range of the value expected based on the receiver's local clock. The packet will be rejected if the time stamp is invalid. When no packets are sent during silence periods or during packet losses, the RC4 states are advanced using a local clock. RC4 state synchronization will advance RC4 state forwards or backwards in order to make RC4 states Nk equal to Nf_next (Ne+Nm). An authentication check is performed on a MAC key and one random pad from RC4. The states transitions are controlled by the system configuration parameters and received packet timestamps.
Although the PacketCable Security Specification provides guidance for security measures in its implementation, the standard will not operate correctly when a codec or MAC change occurs during a call transmission. The lack of a proper timestamp for transitioned packets prevents the receiver from synchronizing with the transmitter. Therefore, what is needed is a way to adjust the RC4 state to synchronize between the transmitter and the receiving when changing a codec or MAC during PacketCable communications.